


REMARKS 



The above amendment and these remarks are responsive to 
the communication from Examiner Chang Y. Chung mailed 8 August 
2000 in the above cited application, Paper No. 5. 



The Draftperson has objected to the drawings 1-3B due to 
the poor quality of the lines, numbers and letters. Upon 
allowance of the case, applicants will submit formal drawing 
Figures 1-3B with lines, numbers and letters of the required 
quality. 



Claims 1-9 have been rejected under 35 U.S.C. 103(a) over 
Klein (U. S. Patent 5,845,285) in view of Geer (U* S. Patent 
5,930,778) . 



DRAWINGS 



35 U.S.C. 103 
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Applicants traverse the rejection of all of these claims 
on the basis that the Examiner has not established a prima facie 
case of obviousness. The art references on which he relies do 
not suggest a combination which reads on applicants claims and, 
in fact, both specifically teach away from applicants invention 
as claimed. The Examiner has in the rejection of these claims 
assembled a piecemeal reconstruction of prior art patents and 
official notice which could only be done if done in light of 
applicants disclosure. Such a reconstruction or combination is 
clearly based upon an improper hindsight view of the art after 
having the benefit of applicants' disclosure. 

Applicants' invention provides a system and method for 
preventing duplicate invoices from entering a payment 
application (SAP) . Once an invoice is identified as a 
duplicate, it is rejected electronically and in real-time, 
automatically returned to the supplier prior to entering the 
payment application (SAP) for invoice processing. This enables 
automated error notifications (aka 824 transactions) to be sent 
out EDI. An invoice is identified as duplicate if it is of the 
same vendor invoice, the same purchase order number, and the 
same item number, AND has not been previously washed (that is, 
the sum of such invoice items is greater than zero.) Thus, 
applicants define a duplicate invoice as follows: 



"Referring to Figure 2, the auditing step 82 includes, in 
step 88, sorting the inbound invoices against SAP 
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production tables for same vendor and same vendor invoice 
number; in step 90, sorting hits from step 88 for same 
purchase order billed; in step 92, sorting hits from 
step90 for same items billed on purchase order; and in 
step 94 sorting hits from step 92 to see if any item 
identified has a net sum > 0. If an item has net sum ^0, 
it is not a duplicate and is allowed in steps 98 and 86 to 
be posted to the accounts payable data base. If an item 
has net sum > 0, it is a duplicate, and a transaction back 
to the vendor is created in steps 96 and 84 to cancel the 
duplicate invoice." (Specification, page 11, lines 4-15.) 

First, with respect to Klein. Klein relates to a neural 
network based system for auditing data in a database for 
detecting duplicate data. Data already entered into the 
database is sampled and audited. It is important to note that 
Klein is auditing a database by selecting a sample of entries in 
the database and applying a neural network analysis to that 
sample to identify, inter alia, duplicate entries. 

Applicants' invention relates to preprocessing debit 
invoices before they are entered into the accounts payable 
database. Klein teaches a system for auditing a database to 
identify possibly duplicate entries for future analysis. 



Klein simply does not perform the same function or achieve 
the same result as applicants' claimed invention. The Examiner 
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appears to recognize this point in stating that "Klein does not 
explicitly teach preprocessing of invoices", and "Klein does not 
explicitly teach introduction to and rejection from a accounts 
payable data base." (See page 3 of the Office Action.) He then 
relies on Kline and various assertions of "obvious to one of 
ordinary skill in the art..," not supported by reference to any 
specific teaching in the art, to reject applicants claims. 

With respect to Geer. Geer relates to the efficient 
submission of checks and other financial instruments into the 
payment system for collection of funds. The Examiner asserts 
that Geer teaches "preprocessing of original invoices before 
introduction into a database". Applicants traverse this 
characterization. What Geer may properly be viewed as teaching 
is a data capture step, in which information from a check is 
obtained by electronic scanning and communicated electronically 
into a check clearing system by a payee. The whole objective of 
Geer is to electronically capture and transmit check data into 
the payment system so as, in his first example, to avoid the 
necessity of transferring the physical checks from the payee to 
the payor bank, or, in his second example, to allow check 
processing to continue through the payment system without 
waiting for the physical transfer of the checks. These checks 
are received by the payee from a customer together with a 
remittance advice, that is a payment stub or invoice copy, so 
that the check amount can be properly credited to the payee 
customer's account. Geer is not a system for receiving invoices 
EN998071 15 S/N 09/244,304 



for payment, but rather a system for receiving checks in payment 
of invoices. There is no teaching in Geer of preprocessing 
invoices as claimed by applicants. Geer can only be fairly 
interpreted to teach that data from the checks are scanned and 
introduced into the payment system for subsequent checking and 
transaction reversal if, for example, it is determined that 
there are insufficient funds to cover the check or a stop order 
has been placed on the check. 

Applicants invention relates to preprocessing of invoices 
to detect and reject duplicate invoices before they make it into 
the accounting system database. It is singularly important to 
realize that in Geer, a check or instrument submitted for 
collection is well into the financial system before action is 
taken for reversal. 

"In the event of dishonor of a check by a payor bank, the 
process reverses as to the collection of the dishonored 
check, and this information may be transmitted 
electronically back through payment system 12 (or by more 
direct means of reversal) to depository bank 10 for 
unwinding the transaction and for debiting of the payee's 
account as to the dishonored check." (Geer, at Col. 9, 
lines 45-50.) 

Thus, to the extent that Geer can be combined with Klein to be 
applied to applicants' invention, Geer teaches away from 
applicants' invention. It is this necessity for unwinding of 
transactions that applicants' invention prevents in the context 
of invoice processing. 

Referring now to applicants claims. 
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With respect to claim 1, the Examiner states that Klein 
teaches at Col. 26, lines 38-43, rejecting data as duplicate 
without introducing the data into the system. Applicants 
traverse this reconstruction of Klein, who clearly states that 
"if necessary, the data may then be corrected" - there is no 
teaching in Klein that the data is checked for duplicate entries 
before being entered into the database being audited. In Klein, 
the data being audited is sampled from the database. 

The Examiner then states that while Klein does not 
explicitly teach preprocessing of invoices (applicants agree), 
Geer discloses at Col. 6, lines 43-45, preprocesing of invoices. 
Applicants traverse this reading of Greer, who states at the 
place referenced by the Examiner: 

Appropriate information from the checks is extracted and 
converted into electronic form for sorting, processing and 
transmission into and through the payment system. (Geer, 
col. 6, lines 41-44.) 

This is merely a data entry step. The data is entered into the 

collection system and must be reversed if later found to be 

erroneous. This was discussed above, in connection with Geer, 

Col. 9 lines 45-50, where dishonored checks are finally 

identified, and the clearance process must be reversed. 

The Examiner then states that Klein does not explicitly 
teach introduction to and rejection from a accounts payable data 
base (applicants agree), but then goes on to say Klein does 
suggest this feature at Col. 26, lines 40-44 and Col. 27, lines 
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22-25. Applicants traverse this characterization of Klein as 
previously discussed. The data being corrected by Klein is 
already in the database being audited. Applicants, on the other 
hand, have provided a specific pre-processing method to avoid 
entering into an accounts payable database invoices which, if 
entered, would be duplicates. Applicants have amended claim 1 
to clarify this distinction over the art references, by 
reciting: 



M ... grabbing [an] inbound EDI invoice [file] files from [a 
vendor] vendors before [it is] they are input to an 
accounts payable database , said grabbing including sorting 
inbound debit invoices and credit invoices in credit/debit 
sequence and posting said credit invoices to said accounts 
payable database ; 

auditing in sequential order of receipt said debit 
invoices in said inbound EDI invoice [file] for a 
duplicate invoice ite m, a duplicate invoice item being an 
invoice item having a net sum > zero determined with 
respect to previously received invoices for the same 
vendor invoice designation, same purchase order number, 
and same item number . . . " (Claim 1.) 

Applicants further assert that the Examiner has used 
impermissible hindsight, and applied applicants' own teachings 
against them in concluding that it would have been obvious to 
one of ordinary skill in the art to "introduce and reject data 
from an accounts payable database because this would allow 
filtering and sorting out to be implemented as soon as data is 
available." No reference or teaching on the record supports an 
assertion that it is desirable to detect duplicate data before 
entry to an accounts payable database, that is as soon as it is 
available, or as soon as possible, and the art references of 
Geer and Klein both teach otherwise. 
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With respect to claim 2, Klein is applied as above with 
respect to claim 1, but then official notice is taken to grab 
data before input into a database. However, in taking this 
notice, the Examiner is going specifically contrary to the 
teachings of Klein, which is sampling data already entered into 
the database for purpose of auditing, and which requires that 
duplicate or erroneous data be "corrected" . In suggesting that 
inbound EDI invoice could be grabbed before inputting it into a 
database to allow detection of duplicate as soon as possible, 
the Examiner is improperly using applicants disclosure against 
their claim. The art does not suggest or even recognize the 
advantage of detecting duplicates as soon as possible, but 
rather much later, in the course of auditing data already 
entered. 

With respect to claim 3, applicants simply traverse. The 
reading of Klein given by the Examiner to suggest Klein teaches 
the specific steps executed by applicants' claim 3 to identify 
duplicate invoices is simply and unquestionably a hindsight 
reconstruction of Klein based on applicants own disclosure. 
Applicants traverse the rejection of claim 3. 

With respect to claim 4, and as previously discussed with 
respect to claim 3, the Examiner states that Klein does not 
explicitly teach grabbing an invoice from a vendor before it is 
input to an accounts payable database and creating a transaction 
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to a vendor. Applicants agree. However , applicants assert that 
only impermissible hindsight reasoning and the use of applicants 
disclosure against the claim provide any basis for the Examiner 
to take official notice of the grabbing step as is specifically 
defined by applicants. The only art applied in this case 
against any of the claims clearly require just the opposite: 
eventual detection of erroneous or duplicate data entries 
require that the database be corrected or entries reversed. 
That is precisely the problem in the art (entry of duplicate 
invoices into an accounts payable database that must be later 
reversed) that applicants' invention as claimed prevents. 

With respect to claim 5, the Examiner's reliance upon Geer 
for the preprocessing step is not supported by the reference 
itself. As previously discussed, erroneous entries to the check 
clearance process of Geer must be reversed. The preprocessing 
which Geer done, and upon which the Examiner relies, is merely a 
data entry step. Checks which will not clear are identified 
much later, and must be reversed. 

With respect to claim 6, the Examiner states that Klein 
does not explicitly teach grabbing, does not explicitly teach 
(the steps applicant claims for identifying duplicate invoices), 
does not explicitly teach communicating a duplicate invoice 
rejection message back to the vendor. Nowhere in the art of 
record is there any teaching of rejecting a computer detected 
duplicate invoice back to a vendor before it is entered into the 
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accounts payable database. Applicants assert that the only 
basis on which these teachings can be implied from Klein 
involves impermissible hindsight reconstruction of Klein based 
upon applicants own disclosure and requires that the specific 
teachings of Klein be discounted. 

With respect to claim 7, the Examiner states that Klein 
does not explicitly teach grabbing an invoice before input to an 
accounts payable database, nor identifying duplicate invoices 
(based upon the net sum analysis performed by a computer), nor 
communicating a duplicate invoice rejection back to the vendor. 
Nowhere in the art of record is there any teaching of rejecting 
a computer detected duplicate invoice back to a vendor before it 
is entered into the accounts payable database. Applicants 
assert that the only basis on which these teachings can be 
implied from Klein involves impermissible hindsight 
reconstruction of Klein based upon applicants own disclosure and 
requires that the specific teachings of Klein be discounted. 
Applicants claim requires that these steps be performed by a 
computer, and Klein specifically teaches that any identification 
of erroneous data in the database being sampled and audited be 
done by a human. 

With respect to claim 8, the Examiner states that Klein 
does not explicitly teach preprocessing of invoices. Applicants 
agree. However, the Examiner then states that Geer discloses 
such. Applicants traverse. As previously noted, Geer relates, 
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at the point cited by the Examiner, to data entry into a check 
clearance system. Erroneous checks are not identified until 
much later, and then require that the entry be reversed. 
Applicants claim further recites the specific, computer executed 
algorithm for identifying duplicate invoices. Neither Geer or 
Klein teach such. The suggestion of the Examiner that it would 
be obvious to filter and sort out duplicate invoices before 
entry into an accounts data base as soon as the data is 
available requires that impermissible hindsight reconstruction 
of Klein and/or Geer based upon applicants own disclosure. 

With respect to claim 9, the Examiner states that Klein 
does not explicitly teach grabbing an invoice before input to an 
accounts payable database, nor identifying duplicate invoices 
(based upon the net sum analysis performed by a computer), nor 
communicating a duplicate invoice rejection back to the vendor. 
Nowhere in the art of record is there any teaching of rejecting 
a computer detected duplicate invoice back to a vendor before it 
is entered into the accounts payable database. Applicants 
assert that the only basis on which these teachings can be 
implied from Klein involves impermissible hindsight 
reconstruction of Klein based upon applicants own disclosure and 
requires that the specific teachings of Klein be discounted. 
Applicants claim requires that these steps be performed by a 
computer, and Klein specifically teaches that any identification 
of erroneous data in the database being sampled and audited be 
done by a human. 
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RESPONSE TO ARGUMENTS 



The Examiner has responded to applicants arguments by- 
stating: 

"...Klein is not used to show preprocessing in examiner's 
rejection. Geer (US 5, 930, 778) specifically discloses 
system for coordinating invoice processing at the point of 
receipt, and is intended to eliminate duplicative data 
(column 5, lines 58-61) . 

Klein teaches: 

"It is a further object of the present invention to 
eliminate duplicative data capture steps and multiple 
handling involved in the payee' s and the bank of first 
deposit's handling of the same payment . .." (Column 5, 
lines 58-61) . 

What Klein goes on to teach is that at the point of receipt, the 
information on a check is electronically scanned and input into 
the system so as to avoid having that data captured at multiple 
places. The invoices which Klein refers to are merely payment 
advices, or payment stubs, used to process the payment against 
an accounts receivable database, not an accounts payable 
database. These are not, in Klein, examined to reject duplicate 
payment advices. Applicants traverse the suggestion that this 
teaches the specific preprocessing of invoices for entry into an 
accounts payable database as set forth in applicants claims. 
All of the checks submitted to the Klein system are scanned and 
input. Applicants are not claiming "coordinating invoice 
processing", but a specific algorithm for determining that a 
debit invoice is duplicate (which is defined to include the sum 
zero calculation in all of applicants claims) and if so 
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determined, preventing that invoice from entering the accounts 
payable database . 

The Examiner also asserts that Geer, at Col, 5 lines 57- 
61, which is quoted above, teaches "invoice processing at the 
point of receipt, and eliminates duplicative data." This is 
referring to data capture, and avoiding the necessity of having 
more than one point in the process capture the data from the 
physical checks. The Examiner is using applicants own teachings 
and creating, at best, a mere verbal correspondence with the 
claims which does not give a required full appreciation to what 
the reference fairly suggests. 

The Examiner then asserts that "one of ordinary skill in 
the art would recognize the original, unfiltered database of 
Klein's system is in effect a temporary database". Applicants 
claim no such "temporary database", and Klein clearly teaches 
that a database is being sampled, and the sample processed. The 
unfiltered database of Klein is used in the neural network 
processing of the data sampled from that database, and cannot be 
properly relied upon to teach applicants system or method for 
processing debit invoices prior to be entered into an accounts 
payable database. 
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SUMMARY AND CONCLUSION 



Applicants request that claims 1-11 be entered and 
allowed, or entered to place the case in better condition for 
appeal . 

If, in the opinion of the Examiner, a telephone 
conversation with applicant (s) attorney could possibly 
facilitate prosecution of the case, he may be reached at the 
number noted below. 



Date: "7 bc^T-PCO 

Shelley M Beckstrand, P.C. 
Attorney at Law 
314 Main Street 
Owego, NY 13827 

Phone: (607) 687-9913 

Fax: (607) 687-7848 



Sincerely, 



M. W. Beach, et al 



By 




EN998071 



25 



S/N 09/244,304 



